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ABSTRACT 

Model  composability  is  a  longstanding  challenge  within  the  simulation  modeling  community.  While  some 
engineering  disciplines  successfully  apply  the  component-based  approach  to  build  systems,  it  has  proven 
significantly  difficult  to  apply  in  simulation  model  development.  This  paper  presents  basic  concepts  related  to 
composability  to  layout  emergent  prospective  issues  with  regard  to  composability.  Given  this  basic  conceptual 
frame,  a  three-tier  strategy  is  suggested  to  advance  the  composability  infrastructure.  Advances  in  the 
infrastructure  are  predicated  on  the  developments  in  theory,  methodology,  and  technology.  Better 
understanding  of  the  conceptual  models  of  composable  simulations  is  argued  to  be  critical  in  improving  the 
technology  for  composition.  In  particular,  making  context  a  significant  component  of  such  a  conceptual  model, 
and  capturing,  packaging,  and  distribution  of  the  context  is  suggested  to  improve  qualification  of  simulation 
models  for  composition.  The  notion  of  an  agent-mediated  model  base  technology  that  uses  intelligent 
matchmaking  and  brokering  mechanisms  to  operate  on  such  context  specification  objects  is  suggested. 

1.  BACKGROUND  ON  COMPONENTS  IN  ENGINEERING 

In  engineering  systems,  hardware  assembly  (composability)  is  paramount  but  not  universally  realizable.  The 
non-universality  is  typical  in  a  systems  approach.  For  example,  the  assembly  of  the  “best”  engine,  the  “best” 
body,  the  “best”  wheels,  and  the  “best”  brake  system  not  only  does  not  end  up  with  the  “best”  car,  but 
components  may  be  completely  incompatible.  Hence,  the  assembly  may  not  be  realizable  at  all.  And  if  by 
some  coincidence,  the  assembly  is  physically  realized,  the  performance  of  the  assembly  may  be  far  from 
being  acceptable  with  respect  to  the  requirements  of  intended  users. 

In  engineering  applications,  the  selection  of  a  hardware  component  cannot  be  done  by  functionality  alone. 
There  are  compatibility  standards  and  each  component  is  labeled  accordingly.  This  type  of  labeling  (or 
documentation)  can  be  named  semantic  labeling  and  has  a  cardinal  role  in  selecting  a  hardware  component. 
Furthermore,  a  given  hardware  component  may  be  interchangeable  with  a  set  of  other  components.  This  type 
of  knowledge  is  also  well  documented  for  hardware  interchangeability  (substitutability).  Hence,  semantic 
labeling  is  necessary  for  pertinence  (applicability)  as  well  as  interchangeability.  Hence,  the  success  of  some 
engineering  fields,  such  as  mechanical  and  electrical,  rely  on  composability  and  interchangeability 
(substitutability)  of  components  into  workable  systems  and  by  nesting,  to  the  realization  of  systems  of 
systems  where  components  are  also  systems.  However,  hardware  composability  and  interchangeability 
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require  a  disciplined  approach  in  developing  hardware  components  and  labeling  (documenting)  their 
characteristics  with  great  care.  A  warehouse  of  hardware  components  without  any  proper  documentation 
about  their  usability  and  compatibility  may  not  be  sufficient  for  successful  practice  of  component-based 
engineering.  Similar  considerations  should  be  taken  into  account  for  successful  practice  of  model 
composability. 

Nayak’s  1995  ACM  Distinguished  Dissertation  showed  that  the  general  model  selection  problem  for 
application  composition  is  NP-hard  (Nayak  1992).  Others  have  shown  that  deciding  whether  an  identified 
collection  of  submodels  meet  a  stated  set  of  objectives  is  an  NP-complete  problem  (Page  and  Opper  1999, 
Petty  et  al.  2003).  Currently  faced  difficulties  of  simulation  model  composability  as  well  as  worst-case 
theoretical  limitations  on  automated  model  selection  (Levy  et  al.  1997)  should  not  be  deterrent  factors  for 
model  composability.  Rather,  necessary  studies  such  as  found  in  (Davis  and  Anderson  2003)  should  be 
conducted  to  overcome  the  apparent  difficulties.  At  one  stage  of  the  maturity  of  modeling  and  simulation  field, 
some  systems  were  (erroneously)  labeled  as  ill-defined  systems.  However,  relentless  studies  have  been 
influential  in  the  advancement  offer  example,  human  behavior  modeling  and  simulation. 

2.  BASIC  CONCEPTS 

In  general,  the  term  “composability”  is  the  quality  of  being  composable  and  means  to  be  capable  or  worthy  of 
being  composed.  Similar  to  other  terms  ending  with  “-ability”,  for  example  acceptability,  it  refers  to  the  objects 
to  which  it  applies  and  not  to  the  agents  (a  model  composer  -  human  or  software)  which  performs  necessary 
acts  to  realize  the  composition  of  models  and/or  model  components.  In  simulation,  three  aspects  of  “model 
composability”  need  elaboration.  These  aspects  are:  related  entities,  related  processes,  and  related 
characteristics  (Figure  1). 

2.1  Entities  -  Model  composability  is  related  to  the  following  entities: 

(el)  A  model  composed  from  other  models  or  model  components.  (This  model  can  be  called 
a  composed  model  (a  synthesized  model,  an  assembled  model),  or  model,  for  short). 

(e2)  Models  or  model  components  from  which  one  can  compose  other  models  (they  are 
elements  of  a  model  base  for  composable  models). 

(e3)  A  model-base  for  models  or  model  components  from  which  one  can  compose  other 
models. 

(e4)  An  entity  (human  or  preferably  a  software  system)  that  composes  (synthesizes)  models 
from  other  models  or  model  components.  This  entity  can  be  called  a  model  composer  or 
composer,  for  short. 

2.2  Processes  -  Model  composability  is  related  to  the  following  processes: 

(pi)  Labeling  of  the  models  and  model  components  in  the  model  base  prior  to  any  search. 
Semantic  labeling  would  entail,  among  other  things,  specification  of  the  intention  (or  goal,  or 
aim)  for  the  use  of  the  model,  applicable  assumptions,  constraints,  etc.  For  a  model 
component,  semantic  labeling  may  necessitate  its  nature  (e.g.,  variable,  constant,  parameter, 
state  transition  function,  output  function,  etc.);  for  a  variable,  one  can  specify  its  type  (input, 
output,  auxiliary  variable;  if  applicable,  physical  units,  upper  and  lower  acceptable  values;  for 
state  variables,  default  initial  conditions,  etc.) 

(p2)  The  process  of  formulation  of  a  set  of  search  criteria  -  based  on  the  intention  or  the  goal 
of  the  user  -  to  detect  relevant  models  and/or  model  components  in  the  model  base, 

(p3)  Searching  the  model  base  according  to  the  search  criteria.  (This  may  require  a  semantic 
search  engine  to  be  developed  for  the  model  base.)  The  result  of  the  search  may  be  some 
plausible  models  and/or  model  components. 

(p4)  Selection  of  relevant  models  and/or  model  components  after  screening  plausible  models 
or  model  components  for  relevancy.  This  is  qualification  and  selection. 

(p5)  Synthesizing  a  model  from  selected  model(s)  and/or  model  component(s).  (This  process 
can  also  be  called  model  composition  or  model  assembly). 
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Figure  1.  Entities  and  Processes  in  Model  Composability 


2.3  Characteristics  -  Model  composability  entails  characteristics  of  the  following  entities: 

(cl)  Characteristics  of  the  composed  model:  Within  this  perspective,  model  composability  is 
the  characteristics  of  a  model  to  be  synthesized  (or  composed,  or  assembled)  from  other 
models  and/or  model  components  into  computationally  (syntactically)  and  logically 
(semantically)  coherent  combinations  that  work  together  within  a  simulation  system  to  satisfy 
the  user’s  intentions. 

(c2)  Characteristics  of  models  or  model  components  from  which  one  aims  to  compose  other 
models:  From  this  perspective,  models  and  model  components  need  to  be  annotated  to  be 
analyzable  for  the  determination  of  possible  detection,  selection,  and  relevance  assurance  for 
model  synthesis.  Hence,  crude  legacy  models  may  need  to  be  preprocessed  for  model 
composability.  High-level  specification  languages  may  be  useful  in  alleviating  the  need  of 
semantic  labeling. 

(c3)  Characteristics  of  model  bases:  A  model  base  can  be  used  for  model  composability,  if 
the  models  and  model  components  it  contains  are  annotated  to  be  analyzable  for  the 
determination  of  possible  detection,  selection,  and  relevance  assurance  for  model  synthesis. 


(c4)  Characteristics  of  a  model  composer:  A  model  composer  needs:  (1)  the  ability  to 
process  intention  of  model  composition,  (2)  the  ability  to  formulate  a  set  of  search  criteria,  (3) 
to  access  a  model  base  of  properly  annotated  models  and  model  components,  (4)  to  perform 
relevance  assessment  of  plausible  models  and  model  components,  and  (5)  the  ability  to 
synthesize  (or  compose,  or  assemble)  models  from  selected  other  models  and/or  model 
components  into  computationally  (syntactically)  and  logically  (semantically)  coherent 
combinations  that  work  together  within  a  simulation  system  to  satisfy  the  user’s  intentions. 


While  engineering  disciplines  successfully  apply  component-based  approach  to  build  systems,  it  has  proven 
significantly  difficult  to  apply  in  simulation  model  development.  As  such,  advancements  in  the  theory, 
methodology,  and  infrastructure  of  simulation  modeling  are  needed  to  facilitate  compositional  development  of 
components  of  simulation  studies,  such  as  simulation  models,  experimental  frames  as  well  as  model  behavior 
generators  and  processors. 

3.  IMPROVING  THE  THEORY,  METHODOLOGY,  AND  TECHNOLOGY  OF  COMPOSABILITY 
INFRASTRUCTURE 

Improving  composability  through  the  realization  of  the  characteristics  of  the  entities  and  processes  identified 
in  section  2  require  advancing  the  theory,  methodology,  and  technology  of  simulation  modeling.  In  particular, 
the  following  prospective  issues  emerge  as  the  challenges  that  need  to  be  addressed  to  facilitate  satisfaction 
of  the  desiderata  listed  in  section  2.3: 
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Figure  2:  Components  of  the  Composability  Infrastructure 

•  How  can  we  improve  the  technology  of  sharing  and  exchange  of  simulations  through 
advanced  model  bases  that  enable  intelligent  brokering  and  matchmaking  between 
simulation  goals  (intentions)  and  contextual  (i.e.,  experiential,  conceptual,  realization) 
assumptions  of  available  models? 

•  From  a  methodology  point  of  view,  what  are  the  components  of  conceptual  models  of 
composable  and  reusable  simulation  models?  How  can  contextual  assumptions  of 
components  can  be  packaged  and  distributed  with  simulation  models  to  facilitate  high 
precision  context-sensitive  search  over  model  bases? 

•  With  regard  to  theory,  are  there  novel  design  constructs  (other  than  popular  but  intractable 
component-connector  strategy)  that  can  facilitate  development  of  a  practical  and  sound 
model  of  composition.  What  would  be  the  proper  underlying  unified  theory  with  uniform 
syntax  and  semantics  for  composition  rules  that  can  take  contextual  assumptions  into 
account? 

Next  we  elaborate  on  each  of  these  issues. 

3.1  Toward  a  Unified  Theory  for  the  Development  of  a  Model  of  Composition 

Model  composability  is  defined  as  the  characteristic  of  a  model  to  be  synthesized  (or  composed,  or 
assembled)  from  other  models  and/or  model  components  into  computationally  and  logically  coherent 
combinations  that  work  together  within  a  simulation  system  to  satisfy  the  user’s  intentions.  A  tractable  theory 
of  composition  based  on  a  sound  framework  is  critical  for  effective  and  practical  composability. 


Concrete  Templates 


Parameterized  Model 


Figure  3:  Parameterized  Composition 


Modular  compositional  development  of  simulations  requires  developing  simulations  in  terms  of  assemblies  of 
standard  models  whose  behaviors  are  already  understood  in  isolation.  Simulation  behavior  must  be 
understood  using  models  and  their  interconnections.  As  such,  a  practical  approach  needs  to  (1)  describe  the 
behavior  and  dependencies  of  each  model  in  isolation,  (2)  use  the  dependencies  among  models  to  derive  a 
model  of  the  behavior  of  the  simulation  as  a  whole,  and  (3)  enforce  the  property  that  behavior  of  the 
composition  involves  modular  composition  of  the  behavioral  specification  of  its  constituent  models.  This  last 
property  is  needed  to  facilitate  practical,  effective  analysis  and  predictability  of  compositions,  as  the  ability  to 
analyze  quickly  the  behaviors  of  many  possible  alternative  compositions  is  essential  to  compositional  design 
of  simulations.  Yet,  there  are  significant  challenges  due  to  the  use  of  common  component-connector 
taxonomy  for  simulation  design.  In  particular,  the  component-connector  strategy  does  not  provide  a  unified 
and  uniform  syntax  (composition  rules)  and  semantics  for  composition.  There  are  alternative  strategies  that 
have  already  been  successful.  At  the  very  basic  simulation  programming  level,  functions  are  parameterized 
components  that  are  instantiated  by  instances  of  their  parameters.  The  foundations  of  composition  via 
parameterization  are  well  studied.  The  question  is  whether  we  can  extend  the  granularity  at  which 
parameterization  is  applied  (as  shown  in  Figure  3).  By  viewing  composition  as  algebra,  compositions  can  be 
constructed  bottom-up  by  binding  actual  parameters  (model  instances)  to  formal  parameters  via  context  and 
substitutability  analysis.  The  semantics  of  composition  can  be  defined  as  the  application  of  the  template  to  the 
specification  of  models  that  depict  the  semantics  of  individual  models.  Such  a  strategy  entails  development  of 
a  composition  strategy  that  captures  the  properties  of  interest  in  a  specific  domain  along  with  the  examination 
of  its  operators  and  the  key  constants.  Some  models  are  instances  whose  concepts  closely  match  the 
constants,  whereas  some  are  templates  that  characterize  the  operators. 

3.2  The  Significance  of  Context  in  Model  Base  Search  and  Model  Qualification 

While  the  significance  of  distinction  between  model,  simulator,  and  experimental  frame  is  clear  and  well 
documented  (Zeigler  at  al.  2000),  one  of  the  least  appreciated,  but  most  significant  aspect  central  to  reuse  is 
the  formalization  of  the  original  context  of  a  model.  The  issue  of  context  is  recognized  as  a  significant  factor  in 
the  reuse  and  sharing  of  knowledge  and  information  (Chandrasekaran  and  Johnson  1993;  McCarthy  1991). 
Situated  view  and  use  of  models  and  knowledge,  in  general,  places  greater  emphasis  on  the  role  of  context. 
Given  the  fact  that  simulation  is  defined  as  goal-driven  experimentation  with  dynamic  models,  the  objectives 
and  the  context  within  which  a  simulation  is  originally  developed  becomes  a  critical  factor  in  qualifying  a 
model  for  composition.  As  such,  the  role  and  significance  of  context  is  undeniable.  Context  entails  at  least  the 
following  three  dimensions:  The  conceptual,  realization,  and  experimental  context.  The  conceptual  context 
relates  the  model  abstraction  to  other  concepts  in  the  domain.  More  specifically,  the  relation  defines  how  the 
semantics  of  the  model  relate  to  the  semantics  of  other  models  in  the  domain  of  the  experimental  study.  The 
realization  context  defines  how  the  implementation  depends  on  other  concrete  components  for  the  completion 
of  its  definition.  The  conceptual  and  realization  contexts  collectively  capture  design  dependencies.  The 
experiential  context  captures  the  experimental  conditions.  Unless  a  simulation  practitioner  (1)  describes  a 
model  formally  to  facilitate  symbolic  reasoning  about  its  fitness  within  a  new  experimental  frame  and  (2) 


understands  the  model’s  contextual  dependencies  accurately  and  unambiguously,  model  reuse  and 
composition  will  continue  to  be  an  ineffective  trial-error  effort.  Hence,  given  this  position,  the  following  issues 
are  worth  exploring: 

•  In  the  context  of  the  modeling  and  simulation,  to  facilitate  the  realization  and  maintenance  of 
precise  relations  among  model  abstractions,  simulation  models,  simulators,  and  the 
experimental  frame,  what  kind  of  dependency  conditions  are  of  interest?  What  are  the 
constituent  elements  of  context  ontology  (i.e.,  elements  of  context)  and  their 
interdependencies? 

•  What  is  the  best  way  to  package  and  distribute  original  contextual  information  along  with 
simulation  models  to  facilitate  improvement  in  understanding  and  sound  reasoning  about  the 
fitness  and  suitability  of  a  model  in  a  new  simulation  context? 

3.3  Agent-Mediated  Model  Bases  for  Context-Sensitive  Retrieval  of  Simulation  Models 

Increased  use  of  simulation  modeling  along  with  continuous  evolution  of  model  bases  are  expected  to  impose 
a  burden  in  effective  model  discovery,  selection,  reuse,  and  composition.  It  is  widely  accepted  that  the 
complexity  of  purpose  and  function  involves  the  context  within  which  a  simulation  is  developed,  composed, 
and  used  (Davis  and  Anderson  2003).  Since  implicit  assumptions  significantly  complicate  model  reuse, 
existing  repositories  need  to  be  augmented  by  mechanisms  that  operate  on  models’  conceptual,  realization, 
and  experiential  contexts.  Two  emergent  issues  are  (1)  the  lack  of  dynamic  brokering  mechanisms  among 
developers  and  constantly  evolving  set  of  services  provided  by  model  providers  and  (2)  the  lack  of  high 
precision  matchmaking  methods  over  explicitly  defined  contextual  model  assumptions.  One  plausible  strategy 
is  to  develop  technology  that  promotes  having  model  producers  and  consumers  represented  by  agents 
providing  services  to  one  another  under  various  forms  of  contracts  in  agent-mediated  model  marketplaces.  In 
this  strategy,  rather  than  require  individual  agents  in  a  model  base  to  locate  relevant  models,  other  specially 
designed  agents  provide  assistance.  Matchmakers  in  this  viewpoint  are  agents  that  maintain  a  continually 
updated  repository  of  information  about  model  providers  currently  in  the  system,  their  capabilities,  and  other 
relevant  information.  Agents  contact  the  matchmaker,  describing  a  task  in  the  hope  of  finding  a  capable  agent 
to  assist.  Brokers  take  this  to  another  level  of  sophistication  in  accepting  tasks  from  requesting  agents, 
assigning  them  to  others.  Unlike  more  traditional  yellow  pages  services,  these  agents  can  perform  partial 
matches,  providing  much  greater  flexibility  than  might  otherwise  be  available. 

4.  CONCLUSIONS 

This  paper  lays  out  basic  concepts  to  advance  composability  through  progress  in  theory,  methodology,  and 
technology.  While  simulation  science  is  founded  on  powerful  foundations,  there  is  still  need  for  improvement 
to  facilitate  addressing  emergent  challenges  of  reuse  and  composability.  As  such,  we  delineate  the 
requirements  and  characteristics  of  a  composability  infrastructure.  We  argue  that,  unlike  ad  hoc  solutions  to 
composability,  advancements  in  simulation  theory  and  methodology  along  with  their  support  in  the 
development  of  next  generation  infrastructures  could  provide  a  sound  basis.  To  this  end,  a  three-tier  strategy 
is  suggested:  (1)  development  of  a  design  for  reuse  methodology  that  facilitates  (embedded)  distribution  of 
conceptual  models  of  reusable  simulations  with  explicit  representations  and  constraints  of  conceptual, 
realization,  and  experimental  context,  (2)  development  of  a  unified  and  uniform  theory  of  composition  that 
uses  parameterization  at  multiple  scales  and  levels,  where  contextual  analysis  and  parameter  substitutability 
play  key  roles  in  composability  analysis,  and  (3)  development  of  an  agent-mediated  model  base  technology 
that  uses  intelligent  matchmaking  and  brokering  mechanisms  that  operate  on  context  specification  objects  to 
perform  context-sensitive  high-precision  search,  retrieval,  and  relevance  assessment  for  qualification  of 
simulation  models. 
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INTRODUCTION 

Researchers  at  the  US  Army  Engineer  Research  and  Development  Center  (ERDC)  and  US  Army  Tank- 
Automotive  Research  and  Development  Center  (TARDEC)  are  collaborating  to  improve  Army  ground  vehicle 
modeling  and  simulation  capabilities.  This  work,  part  of  the  US  Army  Science  and  Technology  Objective 
(STO)  #IV.GC.2003.01,  “High  Fidelity  Ground  Platform  and  Terrain  Modeling  (HGTM)”,  is  centered  on  the 
TARDEC  virtual  evaluation  suite  [1],  which  includes  their  ride  motion  simulator,  Figure  1.  One  of  the  goals  of 
this  effort  is  to  embed  ERDC  vehicle-terrain  interaction  algorithms  [2],  within  the  simulator  software,  such  that 
they  provide  the  forces  between  vehicle  components  (tires  or  tracks)  and  the  terrain.  These  algorithms  need 
parameters  associated  with  terrain  surface  conditions  which  are  functions  of  weather  and  terrain. 

This  paper  describes  the  approach  taken  to  relate  terrain  mechanics  properties  with  the  terrain  database,  in 
sufficient  detail  to  support  the  TARDEC  Ride  Motion  Simulator  and  additionally,  allow  consistency  when 
interacting  with  Semi-Automated  Force  (SAF)  vehicles  within  the  OneSAF  Test  Bed  (OTB),  OneSAF 
Objective  System  (OOS)  and  potentially  other  simulators  or  simulations. 
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Figure  1.  The  TARDEC  Ride  Motion  Simulator. 


BACKGROUND 

Vehicle-Terrain  interaction  algorithms  (terramechanics  software)  describe  how  the  vehicle  dynamics  model 
interacts  with  the  terrain  database.  The  terrain  data  and  the  Ride  Motion  Simulator  visuals  are  based  on  an 
OpenFlight  database.  The  desire  is  to  use  the  OpenFlight  database  to  store  terrain  attributes,  which  can  be 
referenced  to  the  parameters  required  by  the  terramechanics  model.  The  attributes  important  for  predicting 
the  distribution  of  all-season  terrain  parameters  are  soil  type,  drainage,  slope,  aspect,  canopy,  and  elevation. 
Bullock  [3]  developed  methodology  to  infer  soil  strength  values  from  soil  type,  wetness  index,  geographic 
location  and  a  seasonal  parameter  (dry,  average,  wet,  wet-wet).  Following  this  methodology  and  adding 
capability  to  spatially  distribute  snow  and  thawing/frozen  ground,  a  more  distinct  value  of  climate  impact  (e.g., 
monthly,  weekly  or  even  hourly)  is  indexed  to  a  set  of  principal  terrain  mechanics  parameters.  Microclimate 
considerations  suggest  that  soil  type;  wetness  or  drainage  index,  slope,  aspect,  and  canopy  should  provide  a 
unique  set  of  indices  which,  when  combined  with  climatologic  and  geographic  information  will  allow  estimates 
of  the  required  terrain  mechanics  properties  (Table  1).  Table  1  includes  the  corresponding  equivalent 


Environmental  Data  Coding  Specification  (EDCS)  attribute  names  and  definitions,  which  are  in  the  OOS 
terrain  database. 


Table  1.  Terrain  Mechanics  Properties  Required  for  the  HGTM  Terramechanics  Code. 


HGTM  Name 

EDCS1  name 

EDCS  definition 

Terrain  condition2 
(Normal,  Slippery, 
Frost,  Snow,  Ice) 

SURFACESLIPPERY 

Indication  that  a  surface  is  slippery. 

FROZENSURFACECOVERTYPE 

The  type  of  frozen  water  present, 
(none,  ice,  snow,  snow  over  ice, 
slush,  etc) 

Soil  Type 

SOILTYPE 

The  USCS  soil  type. 

TERRAIN  TRANSPORTATION 
ROUTESURFACETYPE 

The  physical  surface  composition  of 
a  road,  runway  or  other  surface 
intended  to  support  the  movement  of 
vehicle. 

Rating  Cone  or 

Cone  Index  at  0-6 
inches 

SOIL  CONE  INDEX  QB 
MEASUREMENT_DEPTH 

Soil  cone  index  at  a  depth:  [0,15], 
[15,30]  where  measurement  depths 
are  in  centimeters. 

Rating  Cone  or 

Cone  Index  at  6-12 
inches 

Snow  Depth 

SNOW_ONLY_DEPTH 

The  depth  of  the  snow,  which  may 
be  over  terrain,  ice  or  floating  ice. 

Snow  Density 

SNOW_DENSITY 

The  density  of  accumulated  snow  on 
an  object. 

Frost  Depth 

FROZEN  SOIL  LAYER 

BOTTOM  DEPTH 

The  depth  from  the  terrain  to  the 
base  of  a  layer  of  frozen  soil. 

Thaw  Depth 

FROZEN  SOIL  LAYER 

TOP  DEPTH 

The  depth  from  the  terrain  to  the  top 
of  a  layer  of  frozen  soil. 

1  Environmental  Data  Coding  Specification  http://www.sedris.org/index.htm 

2  Described  by  more  then  1  EDCS  name 

In  order  to  make  the  terramechanics  code  easily  updated  to  more  complex  models,  and  because  there  is  not 
enough  available  storage  space  in  the  OpenFlight  or  Compact  Terrain  Database  (CTDB)  file  formats  for  all 
these  values,  an  index  or  “type”  which  can  be  related  to  a  unique  set  of  these  values  based  on  time  of  year, 
will  allow  greater  flexibility  to  model  terrain  effects  without  the  need  to  develop  or  recompile  terrain  databases 
for  each  desired  variation  in  season  or  weather.  Currently  there  is  space  in  the  OpenFlight  format  for  a  1 6-bit 
integer,  allowing  65535  different  combinations  of  types.  The  amount  of  space  in  CTDB  (version  7)  is  at  least 
512  (6  bits).  The  current  intent  is  to  develop  the  OpenFlight  database  and  then  convert  it  to  CTDB  format. 
This  code,  as  an  attribute  to  each  polygon  in  the  database  will  need  to  classify: 

1)  Soil  type  (23) 

2)  Drainage  indices  (6) 

3)  Slope  and  Aspect  categories  (27) 

4)  Canopy  indices  (8) 

For  each  combination  of  these  parameters  (HGTM  terrain  code),  within  ranges  of  elevation,  and  that  occur 
within  a  terrain  database,  there  will  be  a  corresponding  set  of  terrain  mechanics  properties  in  a  look  up  table 
(terrain  mechanics  properties  table).  This  allows,  for  example,  different  tables  to  be  developed  for  each 
month  of  the  year  (based  on  climatologic  data  for  the  terrain  database  location).  Alternatively,  the  table  could 
approximate  the  effects  of  a  specific  weather  scenario,  or  actual  measurements.  Conceptually,  the  table  could 
be  changed  during  the  simulation  to  bring  in  dynamic  weather  effects  on  the  terrain. 

The  following  discusses  the  values  selected  to  determine  this  terrain  attribute  code. 

DETERMINATION  OF  SOIL  TYPE  CODES 

The  Unified  Soil  Classification  System  (USCS)  soil  code  was  used  to  associate  soil  behavior  to  traction  of 
vehicle  for  off  road  applications.  Pavement,  shallow  (fordable)  water  and  deep  water  are  also  included; 
discussed  below  are  several  representations,  and  then  the  scheme  selected  for  this  application. 


The  OneSAF  TestBed  operates  on  a  CTDB,  currently  version  7.  Describing  terrain  condition  has  been  a 
continuous  issue  with  the  CTDB  format  and  a  review  of  the  changes  made  as  the  CTDB  evolved  shows  that 
almost  every  version  change  included  a  new  way  to  represent  the  soil  and  its  strength  or  wetness.  The 
following  was  extracted  from  http://www.onesaf.org/extint/fdd/modsaffd.html  for  CTDB  version  7: 

“Attributes  can  be  specified  for  terrain  elements  in  addition  to  the  SIMNET  mobility  index. 

At  a  minimum ,  the  CCTT  soil  type  [(FACC)  code  (STP)],  Surface  Material  Code  (SMC),  and  Surface  Wetness 
Condition  (SWC)  are  associated  with  each  terrain  element. 

Other  FACC  attributes  can  be  associated  with  terrain  using  the  "correction_files"  mechanism  of  the 
"recompile "  program. 

FACC  attributes  of  a  convex  polygon  can  be  changed  by  the  recompile  program  using  the  "correction_files" 
mechanism.  Specified  attributes  are  changed  to  the  new  value  while  other  attributes  of  the  terrain  retain  their 
original  value.  ” 

Birkel  [4]  developed  a  good  summary  of  the  different  soil  codes  available  within  the  CTDB.  Tables  2  and  3 
show  the  codes  and  descriptions  for  SIMNET  and  CCTT  soil  codes.  Additionally,  during  one  of  the  Envirofed 
efforts  [5],  space  was  made  for  Cone  Index  0-6,  Cone  Index  6-12,  Soil  Moisture  0-6  and  Soil  Moisture  6-12. 
These  can  be  set  using  DTSIM  (with  JSAF),  however  it  is  not  yet  know  if  they  can  be  set  using  the  Terrasim 
software  (www.terrasim.com)  used  to  convert  the  OpenFlight  to  CTDB.  Note  that  these  4  integers  along  with 
a  soil  type  are  used  to  define  soil  properties  for  use  by  version  1 .0  of  STNDMob.  STNDMob  (libsoilmobility) 
provides  JVB-OTB  with  maximum  vehicle  speeds  based  on  terrain,  vehicle  type  and  preprocessed  NRMM 
data. 

UAMBL  and  ERDC-GSL  used  9  bits  of  the  CTDB  normally  used  for  SIMNET  soil  types  and  CCTT  soil  types 
to  allow  512  soil/terrain  codes  to  define  soil  properties  via  a  lookup  table  embedded  in  the  libnrmm  code  (a 
pure  C  version  of  libsoilmobility  in  the  UAMBL  version  of  OTB  1 .0).  These  terrain  codes  are  obtained  from 
the  9  bits  in  the  CTDB  for  the  cctt_simnet_soil  and  ctdb_soil  values  (cctt_simnet_soil  =  (ctdb_soil  &  Oxlff). 
Table  4  shows  the  codes  and  the  values  developed  for  a  specific  terrain  file. 


Table  2.  SIMNET  Soil  Types  [4]. 


Index 

Soil  Type 

Description 

0 

SOIL  DEFAULT 

Unknown  type  of  soil 

1 

SOIL  ROAD 

Asphalt  or  other  hard  surface 

2 

SOIL  RCI250 

Packed  soil  or  dirt  road 

3 

SOIL  RCI050 

Soft  sandy  soil 

4 

SOIL  DEEP  WATER 

Impassable  deep  water 

5 

SOIL  SHALLOW  WATER 

Passable  shallow  water 

6 

SOIL  MUD 

Muddy  soil 

7 

SOIL  MUDDY  ROAD 

Wet  dirt  road 

8 

SOIL  ICE 

Slick  ice  surface 

9 

SOIL  SWAMP 

Very  soft  surface 

10 

SOIL  FORESTED 

Canopy  or  forested  area 

11 

SOIL  US  RAILROAD 

Railroad  w /  US  specifications 

12 

SOIL  EURO  RAILROAD 

Railroad  w /  European  specs. 

13 

SOIL  ROCKY 

Small  rocks  <=  18  inches 

14 

SOIL  BOULDERS 

Large  boulders  6  ft.  high 

15 

SOIL_FLIMSY 

Indoor  surface  for  dismounted 
infantry 

15' 

SOILNOGO 

Terrain  that  is  not  traversable 

1  Note  this  index  has  two  meanings,  depending  on  the  terrain  database. 


Table  3.  CCTT  Terrain  Codes  [4]. 


Terrain 

Code 

USCS  Soil  Type  or  Surface  Type 

Qualitative  Soil  Strength 

CI/RCI 

1 

SP,  sw 

Soft 

35 

2 

SP,  sw 

Average 

100 

3 

SP,  sw 

Hard 

130 

4 

SM,  SC,  ML,  ML,  CH,  MH,  OL,  OH 

Very  Soft 

25 

5 

GW,  GP,  GM,  GC,  SM,  SC,  CL,  ML,  CH,  MH,  OL,  OH 

Soft 

35 

6 

SM,  SC,  CL,  ML,  CH,  MH,  OL,  OH 

Average  -  Soft 

50 

7 

SM,  SC,  CL,  ML,  CH,  MH,  OL,  OH 

Average  -  Hard 

80 

8 

SM,  SC,  CL,  ML,  MH,  OL 

Hard 

130 

9 

GW,  GP,  GM,  GC,  SM,  SC,  CL,  ML,  MH,  OL 

Very  Hard 

280 

10 

SM,  SC,  CL,  ML,  MH,  OL 

Hard  (Slippery) 

130 

11 

SM,  SC,  CL,  ML,  MH,  OL 

Very  Hard  (Slippery) 

280 

12 

CH,  OH 

Hard 

130 

13 

CH,  OH 

Very  Hard 

280 

14 

CH,  OH 

Hard  (Slippery) 

130 

15 

CH,  OH 

Very  Hard  (Slippery) 

280 

16 

PT 

Dry  Peat 

40 

17 

GW,  GP,  GM,  HC,  Rock 

Dry  Loose  Surface  Road 

300 

18 

GW,  GP,  GM,  HC,  Rock 

Wet  Loose  Surface  Road 

300 

19 

NO-GO 

Swamps,  Bogs,  Etc. 

10 

20 

Concrete,  Asphalt 

Dry  Pavement 

600 

21 

Concrete,  Asphalt 

Wet  Pavement 

600 

22 

SM,  SC,  CL,  ML,  CH,  MH,  OL,  OH 

Brushland  -  Medium 

80 

23 

SM,  SC,  CL,  ML,  CH,  MH,  OL,  OH 

Brushland  -  Hard 

280 

24 

SM,  SC,  CL,  ML,  CH,  MH,  OL,  OH 

Brushland  -  Medium  (Slippery) 

80 

25 

SM,  SC,  CL,  ML,  CH,  MH,  OL,  OH 

Brushland  -  Hard(Slippery) 

280 

26 

Water  w/  (Silts  and  Clays)  Bottom 

Depth  16  inches 

25 

27 

Water  w /  (Silts  and  Clays)  Bottom 

Depth  33  inches 

25 

28 

Water  w /  (Silts  and  Clays)  Bottom 

Depth  60  inches 

25 

29 

Water  w/  (Bedrock,  Gravel,  Paved)  Bottom 

Depth  16  inches 

300 

30 

Water  w/  (Bedrock,  Gravel,  Paved)  Bottom 

Depth  33  inches 

300 

Table  4.  The  UAMBL  Terrain  Codes  for  the  Libnrmm  Implementation  of  STNDMob. 


Terrain 

code 

Soil 

Type 

Veg. 

code 

Cone  Index 

0-6  inch 

Cone  Index  6- 
12  inch 

Description 

0 

7 

0 

300 

300 

default 

1 

2 

0 

300 

300 

asphalt 

2 

7 

0 

300 

300 

packed  soil  or  dirt  road 

2 

10 

0 

300 

300 

packed  soil  or  dirt  road.  Used  stone  for  SMC 

3 

6 

0 

80 

80 

soft  sandy  soil.  Used  sand  for  SMC 

4 

0 

0 

0 

0 

impassable  deep  water 

5 

7 

0 

100 

100 

passable  shallow  water 

6 

7 

0 

25 

80 

Muddy  soil 

7 

7 

0 

25 

300 

Muddy  road 

8 

7 

0 

100 

100 

slick  ice  surface.  Ice  for  SMC 

9 

12 

2 

25 

50 

Impassable  swamp  in  OTB 

10 

12 

2 

100 

100 

forested  area  in  OTB 

11 

0 

0 

0 

0 

railroad  with  US  specifications 

12 

0 

0 

0 

0 

railroad  with  European  specs 

13 

2 

1 

300 

300 

small  rocks  <=  18  in  high 

14 

2 

2 

300 

300 

large  boulders  6  ft  high 

15 

7 

2 

25 

5 

terrain  that  is  not  traversable 

16 

6 

0 

80 

80 

Poorly  graded/uniform  sands  gravelly  sand  mix 

17 

7 

0 

80 

80 

Silty  sand/silty  gravelly  sands 

18 

8 

0 

100 

100 

Clayer  sands/clayey  gravelly  sands 

19 

9 

0 

75 

75 

Silts/Very  fine  sands 

20 

10 

0 

150 

150 

Low  plasticity  clays 

21 

12 

0 

150 

150 

Highly  plastic  clays  and  sandy  clays 

22 

9 

2 

100 

100 

Soil  in  and  around  orchard 

23 

9 

1 

100 

100 

Soil  in  and  around  vineyard 

24 

7 

0 

300 

300 

Soil  in  and  around  urban  area 

25 

7 

0 

300 

300 

Soil  in  and  around  town  area 

26 

11 

1 

25 

75 

Passable  swamp 

27 

7 

0 

300 

300 

Soil  in  and  around  farm  buildings  -  not  cultivated  fields 

28 

7 

0 

300 

300 

Pipeline 

There  are  23  “HGTM  soil  types”  of  interest  shown  in  Table  5  and  their  relation  to  other  model  representations.  Because  the  terrain 
database  must  be  capable  of  representing  all-season  conditions,  several  classes  of  roads  were  added.  These  are  listed  as  types  17,  18 
and  21-  23  in  Table  5.  This  allows  us  to  differentially  apply  the  seasonal  changes  to  other  trafficable  terrain  types,  specifically,  to  pack, 
plow  or  traffic  the  snow  based  on  road  classification. 


Table  5.  Soils  Types  for  Different  Models  or  Databases. 


HGTM 

Soil 

Type 

Libsoilmobility 

OOS  -  EDCS  SOIL_TYPE 
USCS  Soil  type 
enumerations  and 
TERRAINROUTETYPE1 

NRMM  USCS  soil  and  road 
types  and  (NRMM  soil  group 
code) 

Index 

uses 

soil 

type 

1 

1 

GW 

GW 

GW  (6) 

2 

2 

GP 

GP 

GP  (6) 

3 

3 

GM 

GM 

GM  (4) 

4 

4 

GC 

GC 

GC  (1) 

5 

5 

SW 

SW 

SW  (6) 

6 

6 

SP 

SP 

SP  (6) 

7 

7 

SM 

SM 

SM  (4) 

8 

8 

SC 

SC 

SC  (1) 

9 

9 

ML 

ML 

ML  (3) 

10 

10 

CL 

CL 

CL  (3) 

11 

11 

OL 

OL 

OL  (3) 

12 

12 

CH 

CH 

CH  (2) 

13 

13 

MH 

MH 

MH  (2) 

14 

14 

OH 

OH 

OH  (2) 

15 

15 

Pt 

PT 

Pt  (7) 

ML  AND  CL 

MLCL  (3) 

SM  AND  SC 

SMSC  (4) 

EVAPORITES 

GMGC  (4) 

16 

Rock  (5) 

17 

SECONDARY  ROAD 

Secondary 

18 

PRIMARY  ROAD 

Primary 

SUPER  HIGHWAY 

Super  Highway 

19  -  Shallow  water 


20  -  Deep  water _ 

21  -  Constructed,  well  maintained  gravel  road  with  well  drained,  good  gravel  surface 

22  -  Constructed,  marginal  gravel  road  (constructed,  but  not  always  maintained  or  well 

drained) _ 

23  -  "Two-Track"  road/trail,  made  of  natural  soil  material  (not  constructed  -  but  compacted 

from  traffic) _ 


DRAINAGE  INDEX 

Drainage  index,  table  6,  was  initially  described  by  Bullock  [3]  as  a  wetness  index,  it  is  an  indication  of  how 
easily  the  soil  can  dry  out  or  become  saturated  based  on  drainage  effects,  cone  index  is  directly  related  to  soil 
moisture.  These  correspond  to  the  EDCS  attribute  EAC_SOIL_WETNESS_CATEGORY  enumerations. 


Table  6.  Drainage  Index  Categories  [3], 


Wetness 

Index 

Potential 

Wetness 

Depth  to  Water 
Table 

Depth 

of 

Wetting 

General 

Characteristics  of 

Sites 

EDCS  Attribute  Symbolic 
Constant:  EAC  SOIL 
WETNESS_CATEGORY 
(corresponding  enumerations) 

0 

Arid 

Indeterminable 

Less 
than  1 
ft 

Located  in  desert 
regions. 

PERENNIALLY_DRY 

1 

Dry 

Indeterminable 

1-4  ft 

Steeply  sloping, 
denuded  or  severely 
eroded  and  gullied. 

2 

Average 

More  than  4  ft 

More 
than  4 
ft 

Well-drained  soil  with 
no  restricting  layers 
or  pans;  fair  to  good 
internal  and  external 
drainage.  Slope  may 
be  flat  to  steep. 

MOIST 

3 

Wet 

1-4  ft 

To 

water 

table 

Soil  not  well  drained. 
Restricting  layers  or 
deep  pans  may  be 
present.  May  occur 
at  base  of  slopes,  on 
terraces,  upland  flats, 
or  bottom  lands. 

WET 

4 

Saturated 

Less  than  1  ft 

To 

water 

table 

Sites  waterlogged  of 
flooded  at  least  part 
of  the  year. 
Bottomlands  subject 
to  frequent  overflow. 
Upland  with  poor 
drainage  or  shallow 
pans.  Slopes  with 
very  poor  drainage. 

SATURATED 

5 

Saturated 

Zero  (surface) 

Com¬ 

plete 

Areas  perennially 
waterlogged.  No 
change  in  water 
content  or  soil 
strength. 

WATERLOGGED 

SLOPE  AND  ASPECT  CLASSES 

Aspect  (or  azimuth)  affects  the  amount  of  incident  solar  radiation  thus  influencing  soil  drying  or  snow  melting. 
Aspect  categories  based  on  discussions  with  subject  matter  experts  led  to  the  selection  of  22.5  degree 
increments  with  North  centered  in  the  most  northern  range  (16  categories).  Slope  categories  based  on 
vehicle  mobility  analyses  [6,  7]  are  shown  in  Table  7,  along  with  the  representative  value  used  in  the  terrain 
state  analysis  by  FASST  [8].  However,  for  the  real-time  simulator,  the  impact  of  slope  on  vehicle  performance 
is  explicitly  calculated  by  the  vehicle  dynamics  code,  and  what  is  needed  here  is  for  the  effect  of  slope  on 
terrain  properties,  specifically,  the  spatial  distribution  of  snow  cover.  Analysis  using  an  analytical  model  of 
snowmelt  and  accumulation,  including  solar  energy  input,  led  to  the  combination  of  slope  and  azimuth  shown 
in  Figure  2  and  in  Table  8,  to  account  for  the  spatial  distribution  of  snow  and  freeze/thaw. 


Table  7.  Mobility  Slope  Categories. 


Category 

index 

Range  (%) 

Value  used  in  Terrain 
state  analysis  (%) 

0 

0-2 

1 

1 

>2  &  <=5 

3.5 

2 

>5  &<=10 

7.5 

3 

>10  &  <=20 

15 

4 

>20  &  <=40 

30 

5 

>40  &  <=60 

50 

6 

>60 

? 

Slope 

Class 

0-3 

0 

3-7 

1 

5 

7 

8 

10 

14 

18 

20 

21 

23 

7-10.5 

2 

11 

15 

24 

10.5-  15 

3 

6 

9 

12 

16 

19 

22 

25 

>15 

4 

13 

17 

26 

0  36  72  108  144  180  216  252  288  324  360 

Azimuth 

Figure  2.  Graphical  Representation  of  the  Slope  and  Aspect  Classes  Used  in  the  Terrain  Code  for  Spatially 

Distributing  Snow  Properties. 


Table  8.  Slope/ Aspect  Classes. 


Slope/ 

Aspect 

Class 

Slope  range 
(degrees) 

Azimuth  range 
(degrees) 

Slope/ 

Aspect 

Class 

Slope  range 
(degrees) 

Azimuth  range 
(degrees) 

0 

>  0  and  <  3 

0  to  360 

14 

>  3  and  <  7 

>  180  and  <216 

1 

>  3  and  <  7 

>  0  and  <  36 

15 

>  7  and  <  10.5 

>  180  and  <216 

2 

>  7  and  <  10.5 

>  0  and  <  36 

16 

>  10.5  and  <  15 

>  180  and  <216 

3 

>  10.5  and  <  15 

>  0  and  <  36 

17 

>  15 

>  180  and  <216 

4 

>  15 

>  0  and  <  36 

18 

>  3  and  <  10.5 

>21 6  and  <252 

5 

>  3  and  <  10.5 

>  36  and  <  72 

19 

>  10.5 

>21 6  and  <252 

6 

>  10.5 

>  36  and  <  72 

20 

>  3 

>  252  and  <  288 

7 

>  3 

>  72  and  <  108 

21 

>  3  and  <  10.5 

>  288  and  <  324 

8 

>  3  and  <  10.5 

>  108  and  <  144 

22 

>  10.5 

>  288  and  <  324 

9 

>  10.5 

>  108  and  <  144 

23 

>  3  and  <  7 

>  324  and  <  360 

10 

>  3  and  <  7 

>  144  and  <  180 

24 

>  7  and  <  10.5 

>  324  and  <  360 

11 

>  7  and  <  10.5 

>  144  and  <  180 

25 

>  10.5  and  <  15 

>  324  and  <  360 

12 

>  10.5  and  <  15 

>  144  and  <  180 

26 

>  15 

>  324  and  <  360 

13 

>  15 

>  144  and  <  180 

CANOPY 

The  amount  and  type  of  vegetation  canopy  will  have  an  effect  on  the  amount  of  solar  energy  that  is  imposed 
on  the  ground  surface,  impacting  surface  drying,  freeze/thaw  and  snowmelt.  The  OpenFlight  format  allows 
each  polygon  to  have  a  ground  material  type;  the  classes  of  interest  (those  indicating  some  type  of 
vegetation)  are  shown  in  Table  9.  These  canopy  indices  are  combined  with  the  other  terrain  codes  to  get  the 
actual  surface  conditions.  OpenFlight  allows  other  codes  (ESID,  which  are  extension  of  the  DFAD  codes 
developed  by  Evans  and  Sutherland),  but  these  can  generally  be  mapped  to  the  DFAD  codes  [9]. 


Table  9.  Vegetation  and  Canopy  Codes. 


HGTM 

OpenFlight 

Index 

Canopy 

description 

DFAD  FIC  Classes 

0 

Open 

902 

PHYSIOGRAPHY  -  Soil  (general) 

0 

Open 

906 

Sand/Desert 

0 

Open 

907 

Sand  Dune/Sand  Hill 

1 

Mixed  light 

Marsh,  Wetland,  Swamp,  Bog 

0 

Open 

909 

Rice  Field 

0 

Open 

912 

Rocky  rough  surface 

0 

Open 

913 

Dry  Lake 

0 

Open 

916 

Cleared  Ways 

0 

Open 

934 

Salt  Pan 

1 

Mixed  light 

950 

Vegetation  (general) 

2 

Deciduous  light 

951 

Orchard/Hedgerow 

3 

Deciduous 

dense 

952 

Trees,  Deciduous 

4 

Conifers  dense 

953 

Trees,  Evergreen 

5 

Mixed  Dense 

954 

Trees,  Mixed  (Evergreen  and  Deciduous) 

0 

Open 

955 

Tundra 

2 

Deciduous  light 

956 

Vineyard/Hops 

6 

Non-canopy 

Trail 

Trails  without  a  canopy 

7 

Canopied  trail 

Trails  with  a  canopy 

Trails  (a  soil  or  improved  non-paved  roadway)  with  and  without  a  canopy  are  added  here  to  take  advantage  of 
two  free  indices,  and  to  allow  differentiation  of  soils  which  make  up  a  trail  (soils  on  trails  maybe  of  the  same 
type  as  others  in  the  area,  but  have  a  different  terrain  condition  (stronger,  packed  snow,  etc).  A  little 
information  is  lost  regarding  the  amount  of  canopy,  but  the  ability  to  differentiate  a  trail  from  surrounding  soil  is 
gained. 

ELEVATION  AFFECTS 

Elevation  can  influence  the  amount  of  precipitation  an  area  receives,  and  there  are  models  to  estimate  this 
effect,  snowfall  is  particularly  affected.  Elevation  is  not  included  in  the  HGTM  terrain  surface  type,  but  for 
ranges  of  elevation  (dependant  on  the  weather  condition  scenario  or  measured  data)  multiple  sets  of  the 
HGTM  terrain  mechanics  tables  can  be  created. 

RESULTING  HGTM  TERRAIN  SURFACE  TYPE  AND  TERRAIN  MECHANICS  TABLE 

The  parameters  that  make  up  the  HGTM  terrain  surface  type  are: 


Soil  Type  (23) 

5  bits 

Drainage  indices  (6) 

3  bits 

Slope  and  Aspect  (27) 

5  bits 

Canopy  indices  (8) 

3  bits 

16  bits 

Each  terrain  polygon  is  assigned  a  terrain  code  by  combining  the  bits  for  each  class  or  index  into  a 
hexadecimal  number.  To  accomplish  this,  software  was  developed  which  interfaces  to  the  OpenFlight  API.  It 
queries  every  polygon  in  the  OpenFlight  database  and  checks  for  the  center  of  the  polygon,  while  also 
determining  the  aspect  (based  upon  the  calculated  normal  of  the  polygon)  and  the  slope.  Using  the  center  of 
the  polygon,  tables  containing  the  vegetation  types,  soil  types  and  drainage  characteristic  are  queried.  These 
five  values  are  then  written  into  the  polygon’s  record  according  to  Tables  5,6,8  and  9.  This  modified 
OpenFlight  database  is  then  used  during  the  real-time  simulation  and  is  queried  for  the  surface  type 
information  every  time  step. 


The  HGTM  terrain  properties  table  is  configured  to  be  easily  developed  or  modified  using  a  spreadsheet.  A 
list  of  all  the  HGTM  terrain  surface  types  is  obtained  from  the  OpenFlight  database,  within  specified  elevation 
ranges.  Table  10  shows  how  the  hexadecimal  HGTM  terrain  surface  code  is  translated  in  the  spreadsheet. 


Table  10.  Conversion  of  the  Hexadecimal  Code  to  HGTM  Surface  Types/Classes. 

Bit  Code_ Decimal  Equivalents  HGTM  Surface  Type/class 


Slope- 

Wetness  Aspect  Canopy 


Hexi- 

decimal 

Decimal 

Soil  code 
(5  bits) 

Index 
(3  bits) 

class 
(5  bits) 

Index 
(3  bits) 

Soil 

code 

Slope-  Soil 

Drainage  Aspect  Canopy  code  Drainage 

Slope- 

Aspect 

Canopy 

1B90 

7056 

00101 

011 

10010 

000 

5 

3 

18 

0 

SW 

Wet 

19 

Open 

1A00 

6656 

00101 

010 

00000 

000 

5 

2 

0 

0 

SW 

Avg 

1 

Open 

1B01 

6913 

00101 

011 

00000 

001 

5 

3 

0 

1 

SW 

Wet 

1 

Mixed 

Light 

B09 

2825 

00001 

011 

00001 

001 

1 

3 

1 

1 

GW 

Wet 

2 

Mixed 

Light 

BOB 

2827 

00001 

011 

00001 

011 

1 

3 

1 

3 

GW 

Wet 

2 

Decid 

Dense 

2B0B 

11019 

01011 

011 

00001 

011 

11 

3 

1 

3 

OL 

Wet 

2 

Decid 

Dense 

3B15 

15125 

01101 

011 

00010 

101 

13 

3 

2 

5 

MH 

Wet 

3 

Mixed 

Dense 

315 

789 

00010 

011 

00010 

101 

2 

3 

2 

5 

GP 

Wet 

3 

Mixed 

Dense 

414 

1044 

00010 

100 

00010 

100 

2 

4 

2 

4 

GP 

Sat  4 

2 

Conif 

Dense 

These  terrain  codes  are  permanent  fixtures  of  the  terrain  and  are  used  to  assign  terrain  strength  properties  to 
the  polygon  by  linking  to  a  terrain  mechanics  table  which  is  based  on  the  season  or  weather,  time  of  year,  or 
even  time  of  day.  Table  1 1  shows  the  file  format  for  terrain  properties  indexed  with  the  hexadecimal  code. 
These  terrain  mechanics  properties  are  used  in  the  calculation  of  the  forces  at  the  vehicle-terrain  interface  as 
illustrated  in  Figure  1.  Because  of  this  modular  set  up  of  the  interface  and  terrain  mechanics  table,  the  tables 
can  be  easily  changed  to  accommodate  different  parameters  as  the  interface  code  is  updated  to  more 
sophisticated  vehicle-terrain  models. 

An  application  of  this  methodology  for  the  a  seasonal  terrain  database;  the  Vermont  National  Guard’s  Ethan 
Allen  Firing  Range  in  Northern  Vermont,  is  presented  in  Shoop,  et  al,  [10]. 


_ Table  11.  Sample  Terrain  Properties  Table  with  3  Ranges  of  Elevation. 

Elevation  =  <500 

Terrain  Soil  Surface 


Hex 

Decimal 

Surface 

Soil 

Moisture 

RCI 

RCI 

Cover 

Snow 

Frost  Thaw 

code 

code 

Condition 

Type 

code 

0-6 

6-12 

Depth 

Density 

Depth  Depth 

1B90 

7056 

NOG 

SW 

NOR 

150 

300 

0 

0 

0 

0 

1 A00 

6656 

NOG 

sw 

NOR 

150 

300 

0 

0 

0 

0 

1B01 

6913 

NOG 

SW 

NOR 

150 

300 

0 

0 

0 

0 

B09 

2825 

NOG 

GW 

NOR 

150 

300 

0 

0 

0 

0 

BOB 

2827 

NOG 

GW 

NOR 

150 

300 

0 

0 

0 

0 

2B0B 

11019 

SFG 

OL 

SLP 

100 

200 

0 

0 

0 

0 

3B15 

15125 

SFG 

MH 

SLP 

80 

200 

0 

0 

0 

0 

315 

789 

NOG 

GP 

NOR 

250 

300 

0 

0 

0 

0 

Elevation  <  1500 

1B90 

7056 

SS 

SW 

AVG 

150 

300 

5 

0.3 

30 

0 

1 A00 

6656 

SS 

sw 

AVG 

150 

300 

10 

0.3 

30 

0 

1B01 

6913 

SS 

sw 

AVG 

150 

300 

15 

0.3 

30 

0 

B09 

2825 

FOG 

GW 

AVG 

150 

300 

0 

0 

30 

2 

BOB 

2827 

SS 

GW 

AVG 

150 

300 

10 

0.3 

30 

0 

2B0B 

11019 

SS 

OL 

DRY 

80 

200 

10 

0.3 

0 

0 

3B15 

15125 

FFG 

MH 

SAT 

300 

200 

0 

0 

30 

0 

315 

789 

FOG 

GP 

SAT 

250 

300 

0 

0 

30 

0 

Elevation  >  1500 

1B90 

7056 

SS 

SW 

DRY 

300 

300 

20 

0.25 

30 

0 

1 A00 

6656 

SS 

SW 

DRY 

300 

300 

30 

0.25 

30 

0 

B09 

2825 

SS 

GW 

DRY 

300 

300 

20 

0.25 

30 

0 

2B0B 

11019 

SS 

OL 

DRY 

300 

300 

10 

0.25 

30 

0 

3B15 

15125 

SS 

MH 

DRY 

300 

300 

5 

0.25 

30 

0 

315 

789 

SS 

GP 

DRY 

300 

300 

5 

0.25 

30 

0 

SUMMARY 

A  method  of  linking  current  terrain  conditions  to  an  OpenFlight  database,  without  the  need  to  recompile  is 
presented.  The  current  terrain  conditions  data  supports  high-resolution  terrain  interaction  of  a  ride  motion 
simulator.  Implementation  of  terrain  related  attributes  to  support  both  the  simulator  and  SAF  models  is 
illustrated  in  this  paper. 


ACRONYMS 

CCTT 

CTDB 

DFAD 

DTSIM 

EDCS 

EnviroFed 

ERDC-GSL 

HGTM 

JSAF 

JVB-OTB 

OTB 

OOS 

NRMM 

SAF 

SIMNET 

STNDMOB 

STO 

TARDEC 


Combined  Arms  Tactical  Training  System 
Compact  Terrain  Database 
Digital  Feature  Analysis  Database 
Dynamic  Terrain  Simulator 
Environmental  Data  Coding  Specifications 
Environment  Federation 

Engineer  Research  and  Development  Center,  Geotechnical  and  Structures  Laboratory 

US  Army  Science  and  Technology  Objective  #IV.GC.2003.01,  “High  Fidelity  Ground  Platform 

and  Terrain  Modeling”  project 

Joint  Semi-Automated  Forces 

The  Joint  Virtual  Battlespace  version  of  OTB 

OneSAF  Testbed  Baseline 

OneSAF  Objective  System 

NATO  Reference  Mobility  Model 

Semi-Automated  Force 

Simulator  Networking 

Standard  mobility,  a  set  of  code  based  on  NRMM,  which  predicts  the  maximum  speed 
possible  for  a  ground  vehicle  for  a  given  set  of  terrain  properties. 

Science  and  Technology  Objective 

US  Army  Tank-Automotive  Research  and  Development  Center 


UAMBL 

uses 


Unit  of  Action  Mounted  BattleLab 
Unified  Soil  Classification  System 
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